Finding ID | Version | Rule ID | IA Controls | Severity |
---|---|---|---|---|
V-23747 | NET0812 | SV-41497r1_rule | Low |
Description |
---|
Without synchronized time, accurately correlating information between devices becomes difficult, if not impossible. If you cannot successfully compare logs between each of your routers, switches, and firewalls, it will be very difficult to determine the exact events that resulted in a network breach incident. NTP provides an efficient and scalable method for network elements to synchronize to an accurate time source. |
STIG | Date |
---|---|
Infrastructure L3 Switch Secure Technical Implementation Guide - Cisco | 2017-03-08 |
Check Text ( C-12791r2_chk ) |
---|
Review the router or switch configuration and verify that two NTP servers have been defined to synchronize time similar to the following example: ntp update-calendar ntp server 129.237.32.6 ntp server 129.237.32.7 Some platforms have a battery-powered hardware clock, referred to in the command-line interface (CLI) as the "calendar," in addition to the software based system clock. The hardware clock runs continuously, even if the router is powered off or rebooted. If the software clock is synchronized to an outside time source via NTP, it is a good practice to periodically update the hardware clock with the time learned from NTP. Otherwise, the hardware clock will tend to gradually lose or gain time (drift) and the software clock and hardware clock may become out of synchronization with each other. The ntp update-calendar command will enable the hardware clock to be periodically updated with the time specified by the NTP source. The hardware clock will be updated only if NTP has synchronized to an authoritative time server. To force a single update of the hardware clock from the software clock, use the clock update-calendar command in user EXEC mode. Note: Lower end router models (i.e., 2500 series) and access switches (i.e. 2950, 2970, etc) do not have hardware clocks, so this command is not available on those platforms. Any NTP-enabled device that receives and accepts time from a stratum-n server can become a stratum-n+1 server. However, an NTP-enabled device will not accept time updates from an NTP server at a higher stratum; thereby enforcing a tree-level hierarchy of client-server relationships and preventing time synchronization loops. To increase availability, NTP peering can be used between NTP servers. Hence the following example configuration could be used to provide the necessary redundancy: ntp update-calendar ntp server 129.237.32.6 ntp peer 129.237.32.7 Alternative to querying an NTP server for time is to receive NTP updates via server that is broadcasting or multicasting the time update messages. The following interface command would be configured to receive an NTP broadcast message: ntp broadcast client The above command must be configured on two interfaces or there must be two NTP servers on the same LAN segment broadcasting NTP messages. The following interface command would be configured to receive an NTP multicast message: ntp multicast client 239.x.x.x For multicast, two different administratively scoped multicast groups can be used—one for each NTP server. In addition, the router or MLS must also have ip pim dense-mode configured on the interface as well as global ip multicast-routing. |
Fix Text (F-3044r2_fix) |
---|
Configure the device to use two separate NTP servers. |